Modern travel companies (e.g. airlines) usually employ sophisticated applications for handling reservation requests by customers. It is more and more frequent the case where more than one architecture is used throughout the company system. In such cases compatibility and synchronization issues should be taken into account when designing and planning the reservation system. An example is when part of the reservation management is performed on Internet based applications or communication infrastructures. Another example is when a system (not necessarily a reservation system) must be migrated from a legacy mainframe system (e.g. TPF) to a new system (e.g. an open system). To avoid service interruption in the reservation system, it is advisable to perform this migration progressively, instead of closing down the existing system and switching to the new one in one single move, with all the possible problems which could arise: in addition to the complexity of a big activation procedure at the time of the switch between the old and new system, we should also consider the need of double maintenance of software on both, while the new system is under construction and the old one continues to evolve. Maybe new functionalities must be developed and this requires a double effort, while, if the two systems can work together, all development effort can be dedicated to the new platform. For these reasons, a progressive migration is preferable to a so called “big bang” migration strategy, however some difficulties must be considered. In particular, when the reservation services are distributed between two different platforms (e.g. mainframe and open platforms) they require sharing the same Passenger Name Record (PNR) contextual data in read and write mode to perform their business functionalities.
One of the issues to be considered is the synchronization of data (e.g. PNR data) which are shared in read and write mode across different servers and platforms and across protocols of communication (e.g. TPF mainframe and open systems) so that the systems can share the same up-to-date PNR context data. Co-pending US patent application (claiming priority of EP 11305278.1) “METHOD AND SYSTEM FOR SYNCHRONIZATION MECHANISM ON MULTI-SERVER RESERVATION SYSTEM” filed by the same applicant and having same priority date as the present application, addresses the problem of synchronization across multiple servers (or platform). The method disclosed in such application allows synchronizing the PNR values across the multiplatform system with an efficient and consistent mechanism. The mechanism addresses the consistency and performance issues thanks to its versioning and its lazy behaviour (the synchronization occurs only when required). It can be used as a solution during a migration phase from one system to another with progressive migration of applications sharing data, and also as a permanent solution for distributed applications across different platforms.
The synchronization is performed only when it is needed, and provides only the updates to be done on the local context copy. A key element of the above method is a mechanism to ensure that the most up to date value of a shared parameter is used at any time during the process. In the method and system according to the invention above a distributed shared context correlator is used.
This is called DCX (Distributed context correlator). DCX conveys additional information on top of each message coming from the same user session, on all types of communication protocols to represent the distribution of the applicative contexts on the different platforms and applications, also referred to as machines or application servers.
This DCX entity is created and stored on an Enterprise Service Bus (ESB), which connects the various servers, and is conveyed on all messages within the Amadeus infrastructure in the session header. It contains references to contexts on the different platforms, meaning it does not contain the context data themselves. It is formatted in XML and composed of 3 parts; one reserved for ESB context information used for routing and other use-cases, another part is dedicated to security and user authentication, and finally the third part is the applicative part where application can add their context references and status indicators associated to them. It is in the applicative part that the Context Synchronization process stores the information related to the distributed PNR contexts, and it is the basis of the mechanism.
The DCX offers two other features required for the synchronization mechanism which are the affinity and the context sharing between different communication protocols. The affinity is required to target the exact same application server each time the same service is invoked and it is needed as the PNR contexts are local to application servers. Preferably, the information related to affinity is comprised in keys, which can be referred to as “Affinity Keys”, said keys being comprised in the DCX. The sharing of context information across protocols is required to ensure that a user invoking PNR services on different protocols will still be working on the exact same PNR context.
The lifetime duration of the context is controlled by the established conversations between the ESB and the open system (or the mainframe). The DCX offers a global view of the user activity meaning that if the user works through one specific conversation (for instance EDIFACT conversation), the other protocol conversations will be maintained to ensure consistency across protocols. When the user disconnects from the ESB (by a specific close of conversation or by an inactivity timeout), the conversations to the open systems and mainframe will be also closed and will trigger the clean-up of the contexts. A description of DCX is also available in co-pending applications U.S. Ser. No. 13/065,312 “METHOD AND SYSTEM FOR PROVIDING A SESSION INVOLVING A PLURALITY OF SOFTWARE APPLICATIONS” and U.S. Ser. No. 13/065,273 “METHOD AND SYSTEM FOR PROVIDING A SESSION IN A HETEROGENEOUS ENVIRONMENT” filed by the same applicant and having same priority date of the present application.
While the synchronization mechanism based on DCX is very advantageous in terms of reservation data sharing when implementing a system across multiple platforms, in some cases, e.g. when information are handled and exchanged within a highly distributed Open Back-End platform, it might be preferable to have a centralized handling of the reservation data which could improve the context handling. On a highly distributed environment the synchronization mechanism would imply that all servers are critical (since they all store locally in memory the reservation data) and hey all have to get data from the other servers and this could have impact on the system performances.